home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19950726-19950929
/
000130_news@columbia.edu_Wed Aug 9 12:31:37 1995.msg
< prev
next >
Wrap
Internet Message Format
|
1995-12-25
|
2KB
Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA04916
(5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Thu, 10 Aug 1995 13:24:03 -0400
Received: by apakabar.cc.columbia.edu id AA16184
(5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Thu, 10 Aug 1995 13:24:00 -0400
Newsgroups: comp.protocols.kermit.misc
Path: news.columbia.edu!news.cs.columbia.edu!news.boxhill.com!news.sprintlink.net!noc.netcom.net!netcom.com!mkercher
From: mkercher@netcom.com (Matthew Kercher)
Subject: Re: Packet length and file transfers
Message-Id: <mkercherDD1Msp.pE@netcom.com>
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
References: <3vrtpa$p0r@gold.tc.umn.edu> <4052aj$7cc@apakabar.cc.columbia.edu>
Distribution: USA
Date: Wed, 9 Aug 1995 12:31:37 GMT
Lines: 30
Sender: mkercher@netcom15.netcom.com
Apparently-To: kermit.misc@watsun.cc.columbia.edu
fdc@watsun.cc.columbia.edu (Frank da Cruz) writes:
>In article <3vrtpa$p0r@gold.tc.umn.edu>,
>Jim Scott <scott048@gold.tc.umn.edu> wrote:
>: I've finally managed to get kermit to transfer files reliably and have
>: moved on to the next stage -- improving transfer performance. I download
>: I've got my window slots set to 31, CTS flow control, 57600 speed with a
>:
>: 14.4 modem using compression and error correction. My control prefixing
>: is limited to three characters.
>:
If I infer correctly that you are using MS-Kermit on a PC, you limitation may
be hardware, not protocol strategy. A lame 8250 or 16450 UART on a serial
board or internal modem will loose characters on such high-speed, long packet
receive transfers because it lacks adequate data buffering. This causes
multiple retries. The longer your packet length, the more data that has
to be resent in a bad packet, thus killing the throughput. Keep an eye
on the number of retries during file transfer to get a feel for the size of
the bad packet/lost data problem. Or go buy a good serial board with
a 16550 UART.
--
Matt Kercher
San Francisco, Ca.
mkercher@netcom.com
--
Matt Kercher
San Francisco, Ca.
mkercher@netcom.com